Building a Website that feels ALIVE

Building a personal website honestly sounded pretty simple and fun! I would be able to mess around with web development to create a space that looks and feels like me—my own personal MySpace built by me. But then I started and immediately realized that it was going to take a lot of iterations to turn a simple Vercel-run static portfolio page into the dynamically evolving website that was already floating around in my head. And, really, that tends to be how a lot of websites, and projects in general, go. We have an idea of what the end result should look like, but we have to start with the blank page of unlimited potential.

I realized that I just didn't want a static website—a second resume sitting somewhere in the cloud. I wanted a place that felt alive. I wanted a living, almost breathing, website with dynamic additions that could continually grow. I wanted a system instead of static.

A static site just felt very flat. There could be some interactivity, a link to GitHub or deployed projects. But I wanted a place that could hold all the things that don't belong on a resume. In fact, I realized that I wasn't even planning on putting my resume on my website! I wanted a place to express my thoughts through blogs, share my projects and their progress, and show some personality that can't be captured in bullet points and summaries.

Just like me, I wanted my website to feel like structured chaos—ADHD if it was a website. My website should feel like home: creative, always evolving, always interactive, always crazy, and always fun. The difficult part was figuring out how to turn emotionality into technical architecture. That is something you can't learn in a college classroom.

So I had to start somewhere. After a little bit of research, a couple of credit card number drops, and a creating yet another collection of accounts and logins, I got a domain and a website location! Then came the actual website itself—all the code wasn't going to write itself (yet). I used ChatGPT to scaffold a simple Vercel website for me so I could focus on the Vercel-DNS connection. Then came the content.

I knew what I wanted in my website at first: Blogs and Projects. Using Anitgravity to expand upon the simple code feature by feature was easy. But even after the structure existed, something still felt missing. I didn’t want autogenerated filler content or placeholder text pretending to be personality. I wanted my writing, my projects, and my ideas. That is where Obsidian entered the picture.

I learned about Obsidian during one of the Dallas Software Developers Meet-ups. It wasn't the topic of the night. It just happened to come up in conversation at the table I was sitting at, somewhere between discussions about software tools and why horsepower has multiple measurements. After hearing that it was essentially a powerful Markdown editor, I immediately wanted to try it out! I downloaded it, experimented with it, started building a small personal plugin for organizing my creative writing, and then eventually drifted away from it because life happened.

I downloaded it, experimented with it for a while, even started building a small personal plugin for organizing my creative writing, and then eventually drifted away from it because life happened.

Later, while building the website, I realized something important: I did not want to write blog posts inside an IDE—it felt clunky. Writing is already difficult enough without turning it into a development workflow problem. But Obsidian already writes in Markdown, and Markdown works perfectly for blogs. So I asked myself:

Why not connect Obsidian directly to GitHub and let the website pull from that?

That idea immediately made more sense to me than introducing a database, CMS, or another platform into the mix. I wanted a single source of truth. Obsidian would be where I write, GitHub would synchronize the content, and the website would dynamically pull the data from there.

Using the GitHub API with fine-grained personal access tokens let me connect everything together through the Obsidian Git plugin. In theory, it was elegant: one writing application, one synchronization layer, and one website consuming the content dynamically.

Of course, it was not actually that simple.

Connecting Obsidian to GitHub took far more trial and error than I expected. On paper, it sounds easy: install the plugin, connect your repository, add your token, and everything magically works. In reality, it turned into one of those “but it works on my machine” debugging scenarios where every tiny configuration detail mattered.

The personal access token had to be configured correctly. The repository permissions had to be correct. The plugin settings had to be correct. Everything had to line up perfectly.

After reading documentation, going through walkthroughs, debugging errors, and asking AI why things still were not working, I finally got it running: a blog repository automatically synchronized through Obsidian Git.

And honestly? That tiny feature is probably the part of the website I am most proud of right now. This is still only part one of the current vision for the website. The next major step is dynamically connecting my projects through GitHub as well, allowing the site to evolve automatically as I continue building things. After that, there are other ideas floating around in my head: terminal-like navigation, hidden sections, interactive writing spaces, and a few other things I want to leave vague for now.

I do not really want the website to feel finished. I want it to feel inhabited.

Although the website is still heavily under construction, this project has already taught me a lot.

For one, it reinforced how naturally the Agile development process fits the way I think. I have never been someone who follows rules exactly as written—I tend to treat them more like guidelines—but the core philosophy behind Agile makes perfect sense to me: start with the simplest possible version, iterate constantly, and slowly evolve the system into something grand.

It also changed the way I think about engineering in general. A lot of people imagine engineers as hyper-logical people carrying calculators, notebooks full of equations, and perfectly optimized solutions. But I think engineering—especially software engineering—is actually much closer to art than people realize. Engineers are given constraints, tools, and problems, and then asked to build something meaningful within those boundaries. We inherit decades of solutions from the developers who came before us, but creativity is still required to assemble those pieces into something new. We are all essentially building with the same blocks—what matters is how we arrange them. And I think that applies to websites too.

Personal websites and online portfolios should not just be technical achievements or digital resumes. They should feel intentional and authentic. Someone should be able to open your website and immediately learn something about you from the design, the structure, the interactions, and the overall feeling of the space. A website should feel like an extension of the person who built it. Whether that means an ultra-professional finance site, an artist portfolio full of cat memes, or a creative, left-brained ADHD developer building structured chaos into every corner of the page, your website should feel personal.

It should feel like home.